The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In networks, such as the internet, routers, switches, servers and other network elements process packets. One or more packets make up a flow. A flow is defined as a stream of one or more packets between a particular source and a particular destination and characterized by a specific set of parameters. Different parameters are used by different systems to define a flow. For example, certain processing logic in certain products of Cisco Systems, Inc. categorizes packets into flows called “NetFlows”. In some cases, a NetFlow is a stream of packets that have the same source internet protocol (IP) address, destination IP address, source transmission control protocol (TCP)/user datagram protocol (UDP) port number, destination TCP/UDP port number, IP protocol type, IP type of service, and input logical interface. Thus, if two packets have the same characteristics described in the foregoing sentence, they are considered to be in the same NetFlow. However, other logic may categorize packets into flows by different characteristics. For example, certain logic uses a variation of factors to identify a flow with the following fields: source IP address, source TCP/UDP port number, destination TCP/UDP port number, IP protocol type, IP type of service, and input virtual local area network (VLAN).
Many network elements include a flow table, which stores information collected from all or some of the flows processed by the logic (including data on some or all of the specific packets in the flows). Information collected in certain flow tables may include, for example, the characteristics which define the flow (for example, those characteristics described above). Most (if not all) flow tables are limited in size and cannot store data on an infinite number of flows. Thus, generally, data in a flow table is sent periodically to a collector device or other collecting module for storage and/or use, and the flow table is reset so it can collect data on additional flows of packets. The data in a flow table may be utilized for many purposes, and the information in a flow table provides information about the characteristics of the network activities, for example, for use by a monitoring device or other module.
NetFlow information may be stored in NetFlow software or hardware modules managed by Cisco IOS Software, commercially available from Cisco Systems, Inc., San Jose, Calif.
Various malicious network activities, including port scanning and ICMP attacks, can be directly correlated to malware, hacker, worm or virus activity in a network. Detecting and preventing this malicious activity is extremely important to preserve the normal conditions of a network. Cisco network technology may be used to detect these attacks and to notify a central management device, which can take corrective action. However, in this approach, the reaction may not be prompt enough to mitigate the effects of the malicious activity in the network in a sufficiently timely manner. Further, most network systems have limited-size flow tables, therefore an attacker with an extensive and quick port scan sweep can generate so many new flows that the flow table can overflow and can temporarily lose important statistical data. Still further, in certain networks flow collectors or analyzers are not deployed, and proper reactive counter-measures are not planned or supported.
In some networks, to limit potential flow table utilization and flow data export issues, sampled (instead of continuous) flow collection is used. However, the higher the sampling ratio the longer it takes a security device to collect enough samples to identify a malicious activity. Therefore, using a high sampling ratio can cause delay in reacting to the malicious activity.
Similarly, a fully software-driven connection rate limiting technology can be used to achieve a certain degree of network protection, for example to throttle malicious virus activity. However, any such software-based scheme does often not scale well when applied to hardware-based systems and may not provide timely counter-actions to certain network threats.